If the image differs, but the number of pixels that differ is no more
than tolerated-diff-pixels and the differences are no more than
tolerated-diff-level, then we treat it as a success with warnings, save
the .diff.png for analysis, and use g_test_incomplete() to record the
test-case as "TODO".
Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3195
Applied-upstream: no, upstream want reftests to be a strict pass/fail with identical results required
Gbp-Pq: Topic debian
Gbp-Pq: Name reftests-Allow-minor-differences-to-be-tolerated.patch
Simon McVittie [Sat, 13 Feb 2021 18:26:24 +0000 (18:26 +0000)]
reftest_compare_surfaces: Report how much the images differ
In unattended/non-interactive/autobuilder environments where the images
are not trivially accessible, this provides a way to distinguish between
totally different rendering and more subtle issues.
Signed-off-by: Simon McVittie <smcv@debian.org>
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3195
Applied-upstream: no, upstream want reftests to be a strict pass/fail with identical results required
Gbp-Pq: Topic debian
Gbp-Pq: Name reftest_compare_surfaces-Report-how-much-the-images-diffe.patch
Simon McVittie [Tue, 6 Dec 2022 11:13:59 +0000 (11:13 +0000)]
node-editor: Save test data relative to current working directory
This avoids hard-coding the GTK source directory into the binary, which
would make the binary non-reproducible across different source paths,
particularly in a distro build environment where the source directory
used by autobuilders will often not exist on end-user systems. The node
editor can still be used to create new test-cases by running it with the
GTK source directory as its current working directory.
Bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/5403
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5297 Signed-off-by: Simon McVittie <smcv@debian.org>
Gbp-Pq: Name node-editor-Save-test-data-relative-to-current-working-di.patch
Simon McVittie [Wed, 23 Nov 2022 21:26:50 +0000 (21:26 +0000)]
testsuite: Don't create .test files for flaky or failing tests
These tests can be run manually, but are not suitable for use as an
acceptance test, so let's not make frameworks like Debian's autopkgtest
run these when they run ginsttest-runner in the most obvious way.
Simon McVittie [Wed, 23 Nov 2022 19:13:32 +0000 (19:13 +0000)]
testsuite: Use separate setups for unstable tests instead of should_fail
There are two possible interpretations of "expected failure": either
the test *must* fail (exactly the inverse of an ordinary test, with
success becoming failure and failure becoming success), or the test
*may* fail (with success intended, but failure possible in some
environments). Autotools had the second interpretation, which seems
more useful in practice, but Meson has the first.
Instead of using should_fail, we can put the tests in one of two new
suites: "flaky" is intended for tests that succeed or fail unpredictably
according to the test environment or chance, while "failing" is for
tests that ought to succeed but currently never do as a result of a
bug or missing functionality. With a sufficiently new version of Meson,
the flaky and failing tests are not run by default, but can be requested
by running a setup that does not exclude them, with a command like:
meson test --setup=x11_unstable --suite=flaky --suite=failing
As a bonus, now that we're setting up setups and their excluded suites
programmatically, the gsk-compare-broadway tests are also excluded by
default when running the test setup for a non-broadway backend.
When running the tests in CI, --suite=gtk overrides the default
exclude_suites, so we have to specify --no-suite=flaky and
--no-suite=failing explicitly.
This arrangement is inspired by GNOME/glib!2987, which was contributed
by Marco Trevisan.
Carlos Garnacho [Sat, 4 Feb 2023 12:10:42 +0000 (13:10 +0100)]
gdk/x11: Reset all scroll valuators on enter
We no longer need to make much distinction between multiple logical
devices, plus it breaks esp. with the Xwayland input device distribution.
Just iterate across all devices and reset their scroll valuators.
The owner_events=TRUE grab makes GDK on X11 see events happening
outside every client window as received on the grab window.
Additionally check that the pointer is inside the grab window
(i.e. it received GDK_CROSSING_NORMAL crossing events for the
core pointer) in order to handle clicks happening outside client
windows.
These new paths are expected to be a no-op on Wayland, and to
also work for touchscreen input on X11, due to emulated pointer
events.
- Optimize column views by not creating list item widgets in columns
that are not visible (GNOME/gtk!5374)
- In X11, make sure menus, popovers etc. don't interfere with ability
to click/select in other applications' windows
(GNOME/gtk#5364, GNOME/gtk#5400)
- Do not mark non-user-facing strings as translatable (GNOME/gtk#5146)
- Fix animations and transitions randomly stopping (GNOME/gtk#4426)
- Translation updates: ab, tr
Simon McVittie [Tue, 3 Jan 2023 10:22:42 +0000 (10:22 +0000)]
d/run-tests.sh: Use dh_auto_test
In particular this forces the C.UTF-8 locale, which should mean the tests
pass even when run under a non-UTF-8 locale like C (which official Debian
buildds do not do, but some other environments like reproducible-builds
might).
Calling gdk_device_get_direction can trigger a
notify::direction emissions, since the X11 backend
determines the direction on demand. Prevent that by
forcing the direction to be determined ahead of time.
Carlos Garnacho [Wed, 7 Dec 2022 12:16:36 +0000 (13:16 +0100)]
gdk/x11: Clear all data in GdkSurfaceX11 finalization
Currently, the GdkSurfaceX11 implementation relies that the upper
layers hid the surface before destruction, and that no
GdkSurfaceClass.compute_resize happened between them. If these
circumstances happened, there would be a compute_size timeout left
dangling after the surface got destroyed, poking at incorrect data
later on. Something that looks like this was reported in the
recent mutter-x11-frames "SSD frames server":
mutter-x11-frames:423016): GLib-GObject-WARNING **: 19:41:16.869: invalid unclassed pointer in cast to 'GtkWindow'
Thread 1 "mutter-x11-fram" received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7ffff7f7c4f8 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../../../glib/gmessages.c:1433
1433 ../../../glib/gmessages.c: No such file or directory.
(gdb) bt
#0 g_logv (log_domain=0x7ffff7f7c4f8 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../../../glib/gmessages.c:1433
#1 0x00007ffff73470ff in g_log (log_domain=log_domain@entry=0x7ffff7f7c4f8 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7ffff7f84da8 "invalid unclassed pointer in cast to '%s'")
at ../../../glib/gmessages.c:1471
#2 0x00007ffff7f72892 in g_type_check_instance_cast (type_instance=type_instance@entry=0x5555558e04b0, iface_type=<optimized out>) at ../../../gobject/gtype.c:4144
#3 0x00007ffff791e77d in toplevel_compute_size (toplevel=<optimized out>, size=0x7fffffffe170, widget=0x5555558e04b0) at ../../../gtk/gtkwindow.c:4227
#4 0x00007ffff7f4f3b0 in g_closure_invoke (closure=0x555555898cc0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffdeb0, invocation_hint=invocation_hint@entry=0x7fffffffde30)
at ../../../gobject/gclosure.c:832
#5 0x00007ffff7f62076 in signal_emit_unlocked_R
(node=node@entry=0x55555588feb0, detail=detail@entry=0, instance=instance@entry=0x55555560e990, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdeb0)
at ../../../gobject/gsignal.c:3796
#6 0x00007ffff7f68bf5 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffe050) at ../../../gobject/gsignal.c:3549
#7 0x00007ffff7f68dbf in <emit signal ??? on instance 0x55555560e990 [GdkX11Toplevel]> (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
#8 0x00007ffff7a8de96 in gdk_toplevel_notify_compute_size (toplevel=<optimized out>, size=size@entry=0x7fffffffe170) at ../../../gdk/gdktoplevel.c:112
#9 0x00007ffff7a4b15a in compute_toplevel_size (surface=surface@entry=0x55555560e990 [GdkX11Toplevel], update_geometry=update_geometry@entry=1, width=width@entry=0x7fffffffe220, height=height@entry=0x7fffffffe224)
at ../../../gdk/x11/gdksurface-x11.c:281
#10 0x00007ffff7a4c3b2 in compute_size_idle (user_data=0x55555560e990) at ../../../gdk/x11/gdksurface-x11.c:356
#11 0x00007ffff733f67f in g_main_dispatch (context=0x55555563f6e0) at ../../../glib/gmain.c:3444
#12 g_main_context_dispatch (context=context@entry=0x55555563f6e0) at ../../../glib/gmain.c:4162
#13 0x00007ffff733fa38 in g_main_context_iterate (context=0x55555563f6e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:4238
#14 0x00007ffff733fcef in g_main_loop_run (loop=loop@entry=0x5555560874a0) at ../../../glib/gmain.c:4438
#15 0x0000555555557de0 in main (argc=<optimized out>, argv=<optimized out>) at ../src/frames/main.c:68
It perhaps makes sense to warn in these situations, but either way
it sounds like gdk_surface_x11_finalize() could enforce the correct
behavior by ensuring there is no dangling timeouts/data. This commit
does that.
Calling gdk_device_get_direction can trigger a
notify::direction emissions, since the X11 backend
determines the direction on demand. Prevent that by
forcing the direction to be determined ahead of time.
Corey Berla [Tue, 29 Nov 2022 00:32:52 +0000 (16:32 -0800)]
atspicontext: Cache empty atspi bus address
We are caching the bus address as data on the display object when it
exists, but fail to set the data when the bus address doesn't exist.
That causing excessive calls to GetAddress when the accesssbility
bus doesn't exist. Make sure to cache a non-existent accessibility
bus by setting the "" string.
Corey Berla [Sun, 27 Nov 2022 22:12:36 +0000 (14:12 -0800)]
atspicontext: Log failure to connect to a11y
GTK depends on the a11y infrastructure to be in place unless GTK_A11Y is
set to none. It appears that despite that, users attempt to
get around the a11y requirement without setting GTK_A11Y.
This can cause, amongst other issues, performance problems
with gtk applications. Log failure to connect to the a11y
bus.
projects / gtk4.git / log